New player experience (V453000 & Abregado) In the last several weeks/months we have been working on deciding the fate of the campaign and the demo/tutorial missions. Hi, I'm Ben (Abregado). My experience as an educator using Factorio in the classroom means I have thoroughly examined new players (young and old), and have played the first 30 minutes of Factorio for as many hours as some players spend on a single megabase. The systems in Factorio are deep and interconnected, so creating an onboarding experience for a single concept poses many exciting challenges. We find that the Freeplay portion of the game is already enjoyable to its target audience, but those who prefer a more guided experience only get a short campaign which doesn’t even utilize all of the features we’ve added to the game. On top of that brand new players need to dig through a tutorial which takes about 30-45 minutes to get to automation, which is what the game is about. We want to keep the demo so that anybody who wants to try the game can do it for free, and get a proper representative introduction to what Factorio is. For Factorio, the demo should serve a dual purpose of a tutorial and a teaser, both of which we feel could be improved... Currently we find the demo has the following problems: The impact of the first level isn’t very visually representative of what Factorio is. Gives the impression of being a Minecraft clone in the first tutorial mission by having to mine manually and do hand crafting. Key concepts like Assembling machines and electricity are not presented for the first two levels. Player actions are so heavily constrained that the player learns just how to solve the tutorial rather than learning the concepts we are trying to demonstrate. Each of the levels is disconnected from the previous. Which item recipes are available, that there are suddenly built structures and the location is completely different. Grindy tasks like obtaining X resources in 2nd tutorial mission don’t have any clear purpose. The player does it because they are being told to, not to achieve some other goal that would make sense in the progression. A lot of information is not important and just floods the player with noise, for example many of the messages. The places where the player gets information are scattered - Objective window in the top left, the player character talking to themselves in the console chat and the yellow "TAB bubbles". The three different information channels competing for attention. In this case also two of them telling you the same self-explanatory information (where is the current objective shown, if you didn’t get it), while the chat informs you that your character is alive. A typical objective without purpose. (I guess the game will tell me what is it for soon?) Doesn’t this message resemble another game? What we would like to achieve with the new design: Create an immediately gripping environment that better sets up the Factorio feel. Showing and teaching core concepts like Assembling machines and electricity in the first level using as little complexity as possible. Providing goals through the technology tree, working with laboratories and the technology GUI as soon as possible. Standardize the way players obtain new items. Every recipe has to be obtained through a technology - that way the player triggers recipe progression and gets them as a reward. Starting a new level should start the player at a similar progression state where the previous mission left off. Teaching by experimentation instead of jumping through arbitrary tasks. Letting the player coming up with their own solution of a puzzle. Unify the channels the player gets information from (mostly GUI improvements). After finishing the demo, the player should be ready to continue by playing the main campaign, or jump straight to the Freeplay. If you had to pick one entity that represents the game to you the most, which one would it be?
Bugfixing report (posila) Stabilization goes well, the game seems to be quite stable right now (as in - not many crashes are being reported), in fact I think we are at the phase where additional bugfixing makes the game less stable, because more bugs are introduced than fixed, or some critical bug slips through our automated tests. But there are still lot of issues that need to be resolved before we declare 0.16 stable and move on to 0.17 development - the largest issue being belt compression problems. We finally fixed compatibility problem with OS X 10.9 Mavericks after it was broken in 0.15.40, when we updated our development environment to a newer version of boost, and was still broken in 0.16.x despite of us completely replacing boost with standard libraries from a newer version of C++. However, we might drop Mavericks support in 0.17, as we are considering migrating the game to OpenGL 4.1, which won’t be available on Macs that are unable to run a newer version of macOS. Speaking of OpenGL, we have several reports of the game crashing in rendering on Linux when the game is disturbed somehow (for example window resizes, loses focus or user switches workspaces), even though it is terribly inconvenient, the game seems to be otherwise playable on these configurations, and we don’t want to spend a terrible amount of time trying to figure out what is wrong with our current rendering system, when we plan to do complete overhaul of it in 0.17. We will investigate these issues, but they might go unresolved until 0.17. I’ve been looking into some corrupted saves this week, still not being able to figure out how these mysterious corruptions occur. For example this save had two iron ore entities on two different chunks saved with zero entity ID. This could have happened only if those entities had a wrong pointer to the iron ore prototype, so when the game read the ID from the prototype on saving, it would read a value from some random part of memory, or if the ID was corrupted on copying from the prototype to buffer that is saved to disk. Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?), but it would be nice to have some proof it is not some dangling pointer in our code that causes random parts of memory to be overwritten by who knows what. One way to test it would be to check for tile corruptions. Tile data for a chunk is allocated in a 4kB array at the beginning of the chunk. We could create custom allocator for chunks, so that data structure representing chunk is aligned to virtual pages. That way tile data would occupy a whole single virtual page which we could flag as read only. Then, if due to a bug we write over tile data, the OS would crash the game and we would get a stacktrace and crash dump to investigate. But if a cosmic ray would hit the RAM and flip a bit, the corrupted save would still be produced. However, we currently don’t do any custom allocation of virtual pages, so it might be quite hard to implement. We also need to change tiles sometimes (when map generation runs, when player uses concrete or landfill, when a script changes tiles, etc.) and we don’t know how expensive it would be to change pages from read only to read-write and then back to read only. So it might be just easier to spend two hours on fixing a broken save that someone sends us once every week or two.
Hello dear biters and related species from unexplored planet full of life and natural resources. Recently I have been working on several high resolution graphics for your best friends - the tank and the player character. In this article I would like to show their updated visuals to you, as well as a sneak peek at how they are produced. The following text may contain traces of automation.
It’s been several weeks since we showed you the graphics for new high resolution circuit connector modules (FFF-202). However now is finally the time when we have them in the game. In this article I will briefly show you what was done both in the graphics and code, and what new benefits are there for you as players and modders. I find the 0.15 version of the circuit connector module has following “problems”: The wire connectors are different from the combinators. Wires sometimes completely overlap, making only one of them properly visible. Modularity - you can somewhat tell what is happening based on the LED states, but it could be much nicer. Connecting a belt always looks weird, while the yellow structure which holds the connector box could be made more specific. Some of the rotations are utterly useless. The Lua definitions are spread over every single entity, so revisiting them all is a big pain.
Hello inhabitants of a remote and unexplored planet full of life, richness and natural resources. The group of entities we are bringing to high resolution currently is the combinators. The main problem with them is the amount of shifting values needed, so we used a specific workflow which I will try to show and explain today. Some of the parts have already been described in FFF 146, so I will only mention what is necessary for this article. Please fasten your belt as this will be a ride full of automation.
Hello, it has been a pretty hot week here in Prague, and we have finally wheeled-out and hooked-up our little air-conditioning unit, which has been making a valiant effort to keep the office cool.
Space science As you already know, in 0.15 we have reworked the science packs and added infinite science. More and different science packs make the game a lot more interesting. It reduces the complexity of blue science (which is great for newer players) while adding complexity later, and you now have to decide what to research first, especially with the more expensive game modes (which is interesting for advanced players), and infinite science adds something to do forever in the game. However, one of my biggest complaints about Factorio always was that the rocket has no purpose, even though it is being propagated at all the points as the final step of the game. It is said at the trailer, at the introduction of freeplay, and by being the most advanced research, everything seems like it’s the thing to desire, but when I launched it for the first time and seeing the victory screen, I was feeling like "And now what...". For me there is one main reason why Factorio is so awesome and why I can forget myself playing until 4 a.m., and that reason is the infinite loop of 'there is always a bottleneck', you always need to fix something, you have not enough power, or your production of a particular product is insufficient etc. When you launch the rocket, you escape from this loop because it doesn’t lead anywhere. As we can see, we have learned to take the rocket as a measurable resource sink to quantify the size of our factories, which is great, but I think it makes sense to us only because we got used to it, not because it made sense in the first place, or at least it didn’t to me. Now when 0.15 adds infinite research, I started to ask myself why would I launch the rocket at all, and I have seen many of you ask similar questions. To compare the two, the infinite science is also quantifiable as I can see the amount I produced in the production screen, it also has an interesting crafting recipe (rocket parts vs. all science packs together), and it is also an infinite resource sink. The main difference is, the infinite research is actually useful. This is where the space science comes into play. We now have a space science pack, obtained by launching a rocket. You get 1000 of these science packs per rocket, and every infinite research requires these science packs. Such a simple feature, but it closes the infinite game loop again. But of course in case you want to just launch rockets without worrying about science, you can still do that, just like previously. We have also added more infinite researches, so now apart from worker robot speed, combat robot follower count and mining productivity bonus researches, we also have all of the combative damage upgrades infinite (not shooting speed as that would get ridiculous sooner or later), however their prices increase exponentially to prevent it from getting too extreme. The rocket has to have a satellite in order to get the science packs (the rocket has to be able send back the discoveries, right?). The rocket silo now has an auto-launch checkbox so you can launch them automatically, and the launch is only going to happen when you insert satellite. So you can control the inserter with satellite to only launch rockets when you need the science packs automatically through circuit network. Of course we also added support for mods, so you can define what do you get from sending a rocket, and depending on what you put in the rocket - say, if you put a tank into the rocket, you receive 100 raw fish, because that would make perfect sense. We can build up on this concept in the future, but for now this already brings a lot of sense to the game as it is. As a bonus, here is a album of my factory where I tested the infinite science concept.
Work this week has been progressing nicely on 0.15. We hope we will be able to start our internal play testing soon, as the team works to close off the rest of the major features. Rseding will be arriving here in Prague next week for another of his infamous visits, and Harkonnen will be joining us shortly after, so the office will be prepared for tackling any issues that may arise. Since we are going to be spending the next period polishing and fixing what we already have, you can look forward to some less interesting FFF posts in the coming days. Take the lack of exiting new topics to cover as a good omen that the whole team's effort is on getting everything ready for the release.
While all us minions and assembling humans are furiously working on 0.15, today I would like to present to you what I have been working on lately - new graphics for resources, of course including high res and the new uranium ore. In the second part of the article I will get to an old/new topic about concrete.
Alpha blending and pre-multiplied alpha From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha. When the GPU is figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'): You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque. In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation: Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha. Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending: This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering. For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke. Textures with pre-multiplied alpha also produce better results in texture filtering , which is probably the main reason why they are so widely used in the videogame industry.
